1. Field of the Invention
The present invention generally relates to a data processing system. More particularly, the present invention pertains to a graphical user interface component.
2. Description of the Related Art
A graphical user interface (GUI) has become one of the most widely used mechanisms in which the user interacts with a data or information processing and/or communications system such as a personal computer (PC) or a personal digital assistant (PDA), or a cellular phone, etc. This is partly due to the recent progress in information technologies, both in software and hardware areas, and this is also partly due to the wide recognition of the benefits with which the (well-designed) graphical user interface provides the user in terms of the usability and accessibility, etc. In the graphical user interface paradigm, in the so-called windowing systems in particular, the user interacts with a computer (or other data processing/communications devices) through one or more special areas in the display screen(s), typically of rectangular shapes, called windows. Windows can be opaque or semi-transparent. A special window that covers the whole display screen is generally known as a “desktop” (e.g., in a window system of personal computers). Some windows are configured to display textual or graphical content within their boundaries, such as edit windows used in word processing applications. Other various types of special-purpose or “stock” graphical user interface components, or widgets or controls (or, common controls), are also included in most GUI toolkits or libraries or in most operating systems that natively support graphical user interfaces. (For example, Microsoft Windows, Apple Macintosh, various X-Window based window systems on Unix platforms, and other GUI systems on virtual machines such as Java Swing, Microsoft .Net framework, etc., and Palm, Symbian, and other operating systems for handheld devices or mobile handsets, etc.)
One of the most commonly used GUI controls is a so-called dropdown or dropdown list widget. A typical dropdown list consists of an edit box and a (pull-down) list. An item from the pull-down list may be selected and displayed on the edit box, which may or may not be editable by an end user. An item may also be added to the list either programmatically or by the user (e.g., by adding the item into the (editable) edit box). The list part may be made visible (“pulled down”) or hidden (“closed”) by clicking on the (non-editable) edit box or on a button (typically drawn with a downward arrow) which is usually included in the dropdown list widget. In a typical graphical user interface (GUI) system, only one item may be selected (and displayed through the edit box area). Change of the selected item in the edit box (either in response to user input or initiated programmatically based on other conditions or events, etc.) typically triggers an event, which may be used, for example, to control the behavior of other widgets or to perform certain predefined operations (e.g., through callback functions). The dropdown list control, or simply dropdown control, is sometimes called a combo-box because it provides the combined functionalities of an edit control and a list control (or other type of component). It should be noted, however, that the combo-box control is a single widget in all common graphical user interface systems, libraries, or frameworks, for example, with a well-defined interface (e.g., an application programming interface, or API). In certain implementations, the list control part may always be displayed along with the edit control part (e.g., instead of being toggled between the hidden and pulled-down states). Other variations are also found.
FIG. 1A shows a dropdown list control, or a combo-box, in prior art. The control is displayed in a “closed” state, 102a. The control 102a includes an edit box portion 104 and a pull-down/pull-up (or, show/hide) button 106. The control is typically associated with a list of items (e.g., data) that can be displayed through this graphical user interface widget. The list may come from various data sources such as a document on a file system or a table in a database, etc. The list may also be transient and temporarily constructed (e.g., through a predefined algorithm, etc.) and stored in a volatile memory in the data processing system. When the button 106 is pressed (or, triggered by other mechanisms such as hovering a mouse pointer over a certain part of the widget, etc.), the associated list is displayed (typically, below the edit box), as shown in FIG. 1B. The control is in an “open” or pulled-down state, 102b, with the list box part 108 open in this figure. The “dropped-down” list 108 includes zero or more items 110. The ellipsis is shown in the figure to indicate the drawing is just a partial/schematic representation of the control. When an item is selected (e.g., using a pointer, etc.), the selected item replaces the item displayed in the edit box area 104. A certain additional (predefined) operation may be triggered based on a selection-change event in some applications. The list box may also be closed/hidden (e.g., without changing the selected item, etc.) by using the toggle button 106. In some implementations, the items in the list may be deleted and/or new items may be added to the list (e.g., programmatically, or in response to user input, etc.). In an implementation where the edit box is “editable”, a new item may be added through the edit box area (e.g., by typing in a new item and pressing Enter key, etc.) by the user. The newly added item through the user interface may then be inserted to the original list in the data source.
A related graphical user interface component is a menu control, or a menu bar/strip, which usually consists of one or more menu items. Menu items are typically organized in a hierarchical fashion, and they are designed to trigger certain associated actions when activated (e.g., in response to a user selection). Selecting a non-leaf menu item (e.g., similar to a folder) typically “pulls down” (or, hides) its child menu items (e.g., in the downward direction, or to the right, etc.), in a similar way that a list is displayed (or, hidden) when the combo box is toggled. Selecting a leaf menu item usually issues an associated command which is to perform a predefined function. Unlike the dropdown list component, however, the menu control is primarily used to trigger or issue an action rather than to select an item, and the menu control does not generally change the (parent menu's) label in response to selecting a (child) menu item. FIG. 2A shows a (horizontal) menu bar or menu strip control 152a in the prior art. The (top-level) menu control shown in the figure is in a “closed” state, and it comprises three menu items 154, “File”, “Edit”, and “View”. Menu items can be “opened” by clicking or hovering on the menu items (or, areas on or surrounding the associated labels) using a mouse pointer, or by activating certain predefined keyboard shortcuts. FIG. 2B illustrates the menu bar control 152b in an open or dropped-down state. The “Edit” menu has been pulled down, and its child menu (or, submenu) 156 is displayed below the menu bar. The (vertically arranged) submenu bar 156 includes one or more menu items 158, each of which may open up another submenu or fire up an associated command or action, when activated. Labels of menu items are typically non-editable (e.g., by the user). A menu bar or a submenu bar may be closed either explicitly (e.g., by clicking on the menu, etc.) or implicitly (e.g., automatically when a user interacts with different widgets other than the menu, etc.). Certain aspects of the present invention may apply to a menu control as well as to a dropdown list control, even though our discussion may only refer to a dropdown list control in some cases.
A typical implementation of the dropdown list widget in the prior art is designed to pick an item from a single list of data associated with the widget, add an item to the list, or otherwise manipulate the data in the list. In some cases, the data may be organized into hierarchical lists, such as in the case of a menu component that includes submenus, but each menu (or, submenu) is still associated with a single list (e.g., its child menu items). In certain implementations, the list may be filtered, or otherwise dynamically manipulated, but they still deal with one list. There are cases, however, in which being able to organize items in more than one list (or, select an item from the multiple lists, for example, from different data sources, etc.) is desirable. For instance, listing hundreds or thousands of cities in the United States in one list may not be the most convenient way to organize and/or present the data to the user. Instead, it may be more user-friendly if the cities are grouped, for example, into states and presented in multiple (shorter) lists.